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REMARKS 

Reexamination and reconsideration of this application in view of the following remarks is 
respectfully requested. By this amendment, claims 1, 9, 12 and 17 are amended; no claims are 
currently canceled; and no new claims are added. After this amendment, claims 1, 2, 3, 9, 10, 
11, 12, 17, 18 and 24 remain pending in this application. 

Claim Rejections - 35 USC §112 

Reconsideration of the rejection of claims 9-12 under 35 U.S.C. §112, second paragraph, 
as being indefinite for failing to particularly point out and distinctly claim the subject matter that 
the applicant regards as the invention is requested in view of the amendment to claim 9 and for 
the following reasons. 

The Examiner stated that the following terms in claim 9 were not clearly understood: 
The pair of terms: "regular performance mode" and "reduced performance mode", on the one 
hand; and the pair of terms: "background mode" and "foreground mode", on the other hand. 

The pair of terms: "regular performance mode" (i.e., "non-reduced performance mode") 
and "reduced performance mode" refers to the state of the processor system hardware. These 
terms indicate hardware states that change the amount of power consumed by the processor 
system hardware. 

On the other hand, the terms: "foreground mode" and "background mode" are states of an 
application being executed via an operating system. "Foreground mode" is typically a higher 
priority state than "background mode" and "foreground mode" often has direct user (i.e., human 
being) interaction. A "background mode" typically occurs when an application is far removed 
from direct user interaction, either because the application is waiting for a condition to be met 
before engaging the user, or because the user has an expectation that the application will perform 
its function without further input directly from the user. This is explained in the specification at 
page 20, lines 16 through page 21, line 5. Furthermore, these terms are well established in the 
industry. 

Some examples: Data backup applications often run in "background mode" so that they 
perform their function in a way that the user barely notices. A game application may run in 
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"background mode" to wait for another player to be online before resuming active play in 
"foreground mode". Many instant messaging applications have a "background mode" portion 
that waits for state changes of users in a "buddy list" and only enters a "foreground mode" to 
update those changes on the screen, alerting the user to the change, or when the user initiates 
active messaging. 

In summary, "foreground mode" and "background mode" are states of an application 
(i.e., software), whereas "regular performance mode" and "reduced performance mode" are 
states of the processor system (i.e., hardware) that may be executing the application. 

Therefore, the Applicants believe that the rejection of claims 9-12 under 35 
U.S.C. § 1 12, second paragraph, as being indefinite for failing to particularly point out 
and distinctly claim the subject matter that the Applicants regard as the invention has 
been overcome. 

Claim Rejections - 35 USC §103 

Reconsideration of the rejection of claims 9-12 under 35 U.S.C. § 103(a) as being 
unpatentable over Rawson et al, (U.S. Pat. No. 5,682,204), hereinafter "Rawson", is respectfully 
requested in view of the amendment to claim 9 and for the following reasons. Claim 9 was 
amended to more clearly recite the Applicants' invention. No new matter was added. 

With the Applicants' invention, the operating system software of the electronic device 
accesses resource requirements metadata associated with an application prior to any execution of 
any code of the application. The preceding assertion is supported in the specification. For 
example, see page 15, lines 12-16, which state: 

"The operational flow diagram of FIG. 4 shows an overall process of how the 
wireless device 106, computer readable medium, or computer in FIG. 7 or any other 
electronic device, evaluates the current state of the electronic device and decides 
how an application 350 will or will not be executed by the electronic device." 

The Examiner will note that the above-quoted description of the method in accordance with the 
Applicants' invention, the future tense of the verb "will be" was purposefully used. Use of the 
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future tense of the verb means that the application has not yet started to execute, as of the time of 
evaluation of the current state (i.e., the present state) of the electronic device. The method in 
accordance with the Applicants' invention evaluates the current state of the electronic device and 
decides how an application 350 before the application is executed by the electronic device. 

On the other hand, with Rawson, any resources requirements needed by an application, 
such as power management, are performed only after the application has started, i.e., only after 
some of the code of the application has already executed. Rawson teaches a set of power 
management system calls which may be accessed by either a power management proactive 
application (203) or a Command Script (201). In this way, a script or an application, which is 
already running , is given a way to register its requirements and then to suspend its operation until 
the registered requirements are met. With the Applicants' invention, the resource requirements 
(which may include power management requirements) are attached as metadata to an 
application, so that the operating system may examine the requirements before any portion of the 
application starts to run. Therefore, Rawson teaches away from the Applicants' invention. 

This difference between Rawson and the Applicants' invention is fundamental, and 
changes a great deal about how such a system behaves and operates. As a simple example, with 
the Applicants' invention, the operating system programming is responsible for the portions of 
code that interact with the user to request approval for changes in the performance mode (i.e., 
regular performance mode or reduced performance mode) of the processor. With Rawson, each 
application separately interacts with the user, by having system calls that the application can 
access to change the resource demand during execution. Because each application may have a 
different author, each application will likely interact with the user in a different manner and 
possibly in a confusingly different manner. The Applicants' invention guarantees that the user 
sees a consistent experience provided by the system programming; whereas, in Rawson, each 
application implements its own code by directly executing system calls (see step 604 in FIG. 6 of 
Rawson). 

The following excerpts from the Applicants' specification teach placing the resource 
requirements of an application in metadata associated with the application. See page 12, line 16 
to page 14, line 14 of the Applicants' specification, as follows (emphasis added): 
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"In one embodiment of the present invention, an application resource requirement (ARR) file 352 
associated with the application 350 can also be stored in the storage module 310. ARR file 352 includes 
data related to the application resource requirements associated with the execution of the application 350 
on the wireless device 106. A more detailed description of application resource requirements is provided 
below. ARR file 352 can be a Java Descriptor file (JAD) or other file typically used for holding 
metadata pertaining to another file and be stored as part of the file or in a resource directory such as a 
bat, dat, registry, or other resource file. An exemplary JAD file including power management and 
performance application resource requirements is shown below. 

MIDlet-1: AsteroidsGame, 

Aster oidsGame.png, 

com. mot.j2me. midlets.AsteroidsGame 

MIDlet-Jar-Size: 134859 
MIDlet-Jar- URL: AsteroidsGame. jar 
MIDlet-Name: AsteroidsGame 
MIDlet-Vendor: Motorola, Inc. 
MIDlet- Version: 85. 00. 16 
SMTPServer: idenmoto.com 

iDEN-MIDlet-Performance-FPS-TARGET: 12 // 12 Frames/Second iDEAL 
iDEN-MIDlet-Performance-MIPS-A VG: 5 // Average 5 MIPS 

iDEN-MIDlet-Performance-MIPS_MIN: 3 // Need at least 3 MIPS to Run 

iDEN-MIDlet-Performance-MIPS_BACKG: 0.3 // Need at least 0.3 MIPS 



MIDlet- 1: MP3AUDIOPlayer, MP3AUDIOPlayer.png, 

com. mot.j2me. midlets.MP3A UDIOPlayer 

MIDlet- Jar-Size: 234200 

MIDlet-Jar- URL: MP 3 A UDIOPlayer. jar 

MIDlet-Name: MP3AUDIOPlayer 

MIDlet-Vendor: Motorola, Inc. 



/ / to Run when used in 



iDEN-MIDlet-Performance-Class: None 
iDEN-MIDlet-Performance-IO: None 



// Background mode . 

// Not performance critical App 
//No a factor for this App 
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MIDlet- Version: 85. 00. 1 1 
SMTPServer: idenmoto.com 



iDEN-MIDlet-Performance-FPS-TARGET: 15 // 12 Frames/Second iDEAL 
iDEN-MIDlet-Performance-MIPS-AVG: 50 //Average 50 MIPS 
iDEN-MIDlet-Performance-MIPS_MIN: 35 //Need at least 35 MIPS to Run 
iDEN-MIDlet-Performance-MIPS_BACKG: 10 // Need 10 MIPS when placed on 

II Background Mode 

iDEN-MIDlet-Performance-Class: Medium //Relative Performance App 
iDEN-MIDlet-Performance-IO_SDIO: 44kb //Need BW 'from SDIO port" 



Therefore, because the Applicants' invention uses metadata that is embedded in an 
application, the application does not have to execute in order for the operating system to 
determine the resource requirements of the application. With the Applications' invention, the 
resource requirements of an application can be determined prior to the application running. With 
the Applications' invention, the resource requirements of an application can be determined 
without the application ever running (not even once). This is in contrast with Rawson, which 
requires each application to execute its application code, wherein the application code of Rawson 
makes system calls to provide resource requirements to the operating system. 

Rawson fails to disclose all the steps of amended claim 9. In particular, Rawson fails to 
disclose the second step of amended claim 9, to wit: 

"prior to any execution of any code associated with the application, 

reading an application priority level application resource requirement of the 
application stored in metadata associated with the application, in which the 
application priority level application resource requirement indicates how important it 
is for the processor to execute the application in the regular performance mode;" 



The changes to amended claim 9 are supported by the specification, including, for 
example, at page 15, lines 12-16 (which was reproduced above), and by page 16, lines 1-3, 
which is reproduced below: 
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"In step 406, the electronic device reads the application resource 
requirement (ARR) file 352 associated with the application 350, which is 
stored in the storage module 310." 

Therefore, amended claim 9 should be allowed. Accordingly, the Applicants believe that the 
rejection of claims 9-12 under 35 U.S.C. § 103(a) as being unpatentable over Rawson has been 
overcome. 

Reconsideration of the rejection of claims 1-3, 17-18 and 24 under 35 U.S.C. § 103(a) as 
being unpatentable over Rawson in view of Kozuch et al., (U.S. Pat. No. 7, 225,441) hereinafter 
"Kozuch", further in view of Diepstraten et al., (U.S. Pat. No. 6,243,736) is respectfully 
requested in view of the amendments to claims 1 and 17, and for the following reasons. Claims 
1 and 17 were amended to more clearly recite the Applicants' invention. No new matter was 
added. 

Addressing now specifically the rejection of claim 1. The combination cited by the 
Examiner fails to disclose all the steps of amended claim 1 . In particular, the combination fails 
to disclose the following steps of amended claim 1: 

"prior to any execution of any code associated with the application, the 

operating system reading at least one application resource requirement of the 
application by accessing metadata associated with the application;" 

"wherein if the at least one application resource requirement cannot be 
met by the electronic device, preventing the starting of execution of the 

application," 

The change made to the above-quoted last part of amended claim 1 is supported in FIG. 4 
and at page 21, lines 19-21 of the specification, which states as follows: 
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"In step 412, the wireless device determines whether the application 350 
will be executed, as established above in step 410. If the application 350 is 
executed, control flows to step 414. If the application 350 is not executed, control 
flows to step 418." 

A review of the Applicants' FIG. 4 demonstrates that an application may never even 
begin to start after step 410, which is the step at which the wireless device determines the 
circumstances of execution of the application. Therefore, amended claim 1 should be allowed. 

Amended claim 17 recites similar language; therefore, amended claim 17 should also be 
allowed for similar reasons. 

The Applicants agree with the Examiner's statement, "Rawson does not teach indicating to 
a user that the application cannot be executed on the electronic device, indicating to the user which 
application resource requirement cannot be met by the electronic device, indicating to the user how 
the electronic device can be modified to meet the application resource requirement, prompting the 
user for agreement to modify the electronic device, in response to a command indicating 
agreement, modifying the electronic device to meet the application resource requirement 
associated with the application, and executing the application on the electronic device". 

However, the Applicants disagree with the Examiner that the virtual machines (VMs) of 
Kozuch are analogous to the user of the Applicants' invention, and that the virtual machine 
monitor (VMM) of Kozuch is analogous to the electronic device of the Applicants' invention. 
The Applicants' invention allows for user intervention and agreement by a person, as recited in 
claims 1 and 17. For example, the second element of amended claim 17 recites as follows: 

"a user interface for receiving a command indicating that a user of the electronic 
device desires to execute an application;" 

The electronic device of the invention responds to a decision made by the user by modifying the 
electronic device to meet the application resource requirement associated with the application (if 
such was indeed the decision indicated by the user). Kozuch fails to disclose any human 
intervention in its mechanism. 
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The Applicants agree with the Examiner's statement that Rawson does not teach 
"wherein if the at least one application resource requirement can be met by the electronic device 
when the application executes in the foreground mode, executing the application in the 
foreground mode, wherein if the at least one application resource requirement can be met by the 
electronic device only when the application executes in background mode, executing the 
application in background mode, and wherein if the at least one application resource requirement 
cannot be met by the electronic device, suspending the execution of the application." 

Therefore, the Applicants believe that the rejection of claims 1-3, 17-18 and 24 under 35 
U.S.C. § 103(a) as being unpatentable over Rawson in view of Kozuch has been overcome. 

Conclusion 

The foregoing is submitted as full and complete response to the Office Action dated 
August 4, 2008. It is believed that the application is now in condition for allowance. Allowance 
of claims 1, 2, 3, 9, 10, 11, 12, 17, 18 and 24 is respectfully requested. 

No amendment made was related to the statutory requirements of patentability unless 
expressly stated herein. No amendment made was for the purpose of narrowing the scope of any 
claim, unless the Applicants have argued herein that such amendment was made to distinguish 
over a particular reference or combination of references. 

The Applicants acknowledge the continuing duty of candor and good faith in the 
disclosure of information known to be material to the examination of this application. In 
accordance with 37 CFR §1.56, all such information is dutifully made of record. The foreseeable 
equivalents of any territory surrendered by amendment is limited to the territory taught by the 
information of record. No other territory afforded by the doctrine of equivalents is knowingly 
surrendered and everything else is unforeseeable at the time of this amendment by the Applicants 
and their attorneys. 
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The Commissioner is hereby authorized to charge any fees that may be required or credit 
any overpayment to Deposit Account No.: 50-1556. 

PLEASE CALL the undersigned attorney at (561) 989-981 1, should the Examiner 
believe a telephone interview would help advance prosecution of the application. 



Respectfully submitted, 



Date: November 4, 2008 By: /Jon Gibbons/ 

Jon A. Gibbons, Reg. No. 37,333 
Attorney for Applicants 



FLEIT, GIBBONS, GUTMAN, 
BONGINI & BIANCO P.L. 
551 N.W. 77th Street, Suite 111 
Boca Raton, FL 33487-1330 
Tel (561) 989-9811 
Fax (561) 989-9812 
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